Systems implemented as software have been required to prevent secret information such as keys from being illegitimately analyzed by attackers and processing contents from being overwritten. To address such requirements, techniques have been provided that use mechanisms of access control of operating systems (OSs), obfuscate application programs, invalidate functions of debugger used for analyzing applications, or enhance the access control mechanisms in OSs.
The complete elimination of vulnerability of applications and OSs, however, is actually unachievable. Approaches using software have limitations. For general-purpose personal computers (PCs), approaches have been proposed in which OSs that execute processing to be protected and OSs that execute general-purpose processing are separated using virtual machines. In processors for embedded devices, it is not yet widely used that the hardware has a function to assist virtualization. Thus, it is difficult for the embedded processors having performances inferior to those of the PCs to achieve the same systems as the general-purpose PCs using the virtual machines.
As an example of the systems that address such cases in the embedded processors, a processor architecture is proposed in which a main processor has two modes, namely a secure mode and a non-secure mode. A program required to be protected from attacks such as tampering and analysis is executed in the secure mode while a general-purpose program is executed in the non-secure mode. In this architecture, the OSs, which are operating software for the processor to operate in the secure mode and in the non-secure mode, are individually provided, and processing to encrypt or decrypt data is executed by a secure OS running in the secure mode or by application software running on the secure OS. General-purpose processing such as reading data from a secondary storage is executed by a non-secure OS running in the non-secure mode or by application software running on the non-secure OS. In such a structure, processing is executed while performing the transition between the secure mode and the non-secure mode as appropriate.
In addition, the hardware-based access control mechanism to a memory space makes it impossible for a non-secure OS module to read or tamper with the secure OS. This structure can prevent the secure OS or data of applications running on the secure OS from being stolen or tampered with by software running in the non-secure mode, even if defects (bugs) are built in the non-secure OS module or applications running on the non-secure OS module and the defects are illegally used for the eavesdropping or the tampering. The mechanisms thus can prevent attacks that try to tamper with the processing to be protected or acquire the data to be protected.
Thus a mechanism is provided to separate the OSs and prevent the memory access in the non-secure mode as described above. In such a mechanism, the function operated in the secure mode such as encryption is often required to be explicitly called by a program running in the non-secure mode. Although the explicit calling is required, a function is not provided that periodically and forcibly stops the processing executed in the non-secure mode during the execution thereof, performs the transition of the processing in the secure mode, and generates or processes data in the secure mode. No specific way to achieve such a function is also clearly presented. In addition, no way is achieved to encrypt the data in the secure mode and provide the encrypted data to the non-secure OS.